オンプレからAWS環境にデータベース移行するのに役立つ情報まとめ
西澤です。先日"AWS環境へのデータ移行"をテーマに社内で営業向け勉強会を行ったのですが、自分が1から資料を作るよりもずっと有用な公開資料がたくさんあったので、それらを使って説明をさせてもらいました。当日メンバーから出た質問等も補足しながら、今回はその情報をこちらにまとめておきたいと思います。
前提
タイトルではデータベース移行としていますが、こちらではRDBの移行のみを対象とします。AWSの各種サービスの詳しい説明は行いません。それらを組み合わせて利用する際に必要となる情報をまとめたいと思います。また、これからご紹介する資料の中には重複する部分も含まれるのですが、私が個人的によくまとまっているというところをピックアップしてご紹介して行こうと思います。
AWSへのデータ転送方法のまとめ
まずは、データファイルの転送方法のまとめです。いつの間にかできていた下記ページが非常にわかりやすくまとまっていると思います。
データ転送をする際の課題に合わせて、適切なデータ転送方法が選定できるように必要最低限の情報がバッチリまとまっています。
- インターネット接続の最適化または置き換え
| 要件 | 検討対象 |
|---|---|
| AWS リージョン内のデータセンターに直接接続する | AWS Direct Connect |
| ペタバイト単位のデータのクラウドへのバッチでの移行 | AWS Import/Export Snowball |
| エクサバイト単位のデータのクラウドへのバッチでの移行 | AWS Snowmobile |
| 増分的な変更を伴う定期的なジョブの長距離での移行 | Amazon S3 Transfer Acceleration |
- S3 を直接簡単に使用するためのインターフェイス
| 要件 | 検討対象 |
|---|---|
| ハイブリッドモデルでデータをローカルにキャッシュする (パフォーマンス上の理由) | ゲートウェイ (AWS またはパートナー) |
| ペタバイト単位のデータのバッチでの移行と、オンボードストレージとコンピューティング機能の適用 | AWS Snowball Edge |
| 最小限の中断でクラウドにバックアップまたはアーカイブをプッシュする | テクノロジーパートナーシップ |
| ストリーミングデータの複数のソースを収集して取り込む | Amazon Kinesis Firehose |
特にS3へのデータ転送については、下記ブログも参考にしていただけると嬉しいです。
データベース移行に関するまとめ
続けて、今回の主題であるデータベース移行をテーマにした資料をご紹介していきます。
RDSとRDB on EC2の違い
RDSとRDB on EC2の違いがよくわかる資料がこちら。まずは、RDSファーストで検討しましょう。
例えば、RDB on EC2を利用するケースとして、以下のような理由が挙げられています。
- RDSが対応していないRDBやバージョンを選択したい場合
- RDSの最大CPU数やメモリサイズでは不足する場合
- RDSの最大ストレージ量より大きいディスクが必要な場合
- ストレージ領域の最大サイズは6TB (SQL Serverのみ最大4TB）
- メンテナンス時間を完全にユーザがコントロールしたい場合
- OS側のパラメータ調整、常駐プログラム
- データベースと同じOS上で常駐プログラムを実行可能
- シェルログインでの作業が必要な場合
- OS（カーネル）に何か特殊な設定が必要な場合
- RDSが変更に対応していないDBパラメー タの変更
- ストレージ領域構成の自由度が高い
- 多くのボリュームをOSにマウントし高速化
- REDOログやUNDO表領域のみ別のボリュームに分離
- 一部の表領域に専用のボリュームを割り当て
データベース移行パターンとDMS/SCT活用
データベース移行パターンとDMS/SCTの概要を把握する為の資料はこちらを。AWSへのデータベース移行を促進する為、AWSもDMS/SCTにはかなりを力を入れているらしく、サポートするデータベースエンジンの追加、DWHへの拡張、等、直近でのサービスアップデート頻度が非常に高くなっています。必ず最新資料に目を通すようにしましょう。
例えば、DMS/SCTを組み合わせたデータベース移行の手順の例として、以下のような流れが記載されています。
- SCTでテーブル定義とPK制約を移⾏
- DMSでFullLoadとCDC開始
- FullLoad完了後にFK制約とインデックスを定義
- CDCLatencyが⼩さくなったタイミングで アプリからの書き込み停⽌（ダウンタイム開始）
- マーカーをソースDBにINSERT
- マーカーのターゲットDB到着を確認
- アプリがターゲットDBに接続（ダウンタイム終了）
DMS/SCTを評価する上での注意事項まとめ
少しタイトルから逸れてしまうのですが、そもそもDMS/SCTで綺麗にデータベース移行できるのかどうか？どう判断したら良いのか？という点について質問があったので、注意事項についてまとめておきます。
検証環境を用意して試す
閉域網の準備をして、移行元DBと移行先DBにそれぞれ接続可能な環境が整ったら、まずはデータベース移行の検証を行いましょう。そこで、どのような初期設定が必要なのか、データ移行にかかる時間はどの程度なのか、全てのテーブルをDMSのみを使って正常に移行することができるのか、差分転送でエラーが発生するケースがないか、等を、細かく確認することができます。異なるDBエンジン間の移行を行うのであれば、SCTのレポート機能を使って移行の難易度を測ってみるのも良いでしょう。まず試すこと、試してみて駄目だったら辞めること、が簡単にできることもクラウドを利用する大きなメリットですので、まずはDMS/SCTでデータ移行ができないか確認してみると良いと思います。
プロジェクトのスケジューリング
DMS/SCTは素晴らしいデータベース移行ツールなのですが、もちろんぴったりハマるケースとそうでないケースがあります。ぴったりハマると短期間でのデータベース移行が可能なのですが、万一そうでなかった場合には、必要となる工数、期間が急激に大きくなります。DMS/SCTの利用をまず最初に検討するのは良いのですが、DMS/SCTでデータベース移行が完遂できることを前提にスケジュールを組むのは避けましょう。データベース移行のプロジェクトはスケジュールに余裕を持って進めることをお薦めします。
データ移行が正常に行われたことを確認する方法を決めておく
データベース移行を行う際、何を持ってデータが誤りなく転送されたと判断をするのかということについて、関係者の間で事前に合意しておくことが極めて重要です。レコードの件数とアプリケーションからの動作確認程度で済ませるのか、ランダムに抽出したレコードを比較するのか、ログに異常が無いことをもって正常とみなすのか、等、様々な判定基準があると思いますが、これには正解はありませんので、事前に決めておくしかありません。関係者の間で認識相違が無いように十分に注意しましょう。
DMS/SCTの制限事項や使い方についてドキュメントをよく読む
当たり前ですが、DMSやSCTの公式ドキュメントにはできるだけ細かく目を通しておくと良いでしょう。細かい制限やトラブルシューティング、英語しか無かったものの日本語化等、日々充実していきている印象があります。こまめにアップデートをチェックし、細かく目を通しておくと、事前にトラブルを回避することができると思います。
特に素晴らしいのが、"ユーザガイド"とは別に用意されているAWS Database Migration Service のステップバイステップチュートリアルです。かなり具体的なところまで手順が記載されていますので、マッチする移行ケースでは、大いに参考になると思います。
- AWS Database Migration Service を使用してオンプレミス Oracle データベースを Amazon Aurora に移行する - AWS Database Migration Service
- AWS Database Migration Service を使用した、Amazon RDS Oracle データベースの Amazon Aurora への移行 - AWS Database Migration Service
- MySQL との互換性があるデータベースを AWS に移行する - AWS Database Migration Service
- MySQL との互換性があるデータベースを Amazon Aurora に移行する - AWS Database Migration Service
Oracleのデータ移行手法まとめ
オンプレにあるOracleデータベースをAWSに移行する様々な手法が紹介されているのは、少々古いものですがこちらがよくまとまっています。Oracleネイティブな移行ツールをどのように組み合わせて利用すれば良いかを確認するのに有用な資料になると思います。
Oracleから異DBエンジンへの移行まとめ
先日のAWSサミット東京のセッションで甲木さんからのレポートもあった"Oracle Database から Aurora & Redshift に移行するための実践ガイド"が素晴らしかったので、こちらもご紹介しておきます。
オンプレにあるOracleから、MySQL互換Aurora/PostgreSQL互換Aurora/Redshiftのいずれかにデータベースを移行するケースを想定し、3種類のデータベースエンジンの特徴と違いが細かいところまで網羅されている素晴らしい内容でした。パブリックプレビュー中のPostgreSQL互換Auroraへの期待値には、非常に高いものを感じています。今後、OracleからPostgreSQL互換Auroraへのデータベース移行ケースはどんどん増えていくことが予想されているので、その際にも非常に有用な情報になると思います。
クラスメソッドのコンテンツを活用する
こちらも合わせてご覧いただければ幸いです。
AWS Solution Days 2017 ～AWS DB Day～のレポートがこれまた素晴らしかったので、リンクを追加させていただきます。(2017/07/06追記)
まとめ
移行元/移行先がどこであるにせよ、データベースの移行作業には苦労させられることが多いと思います。AWSのサービスを活用することで、私のようにデータベース管理者としての実務経験が無いエンジニアでも、データベース移行の計画、実行が可能です。そして、何より重要なのは、AWSへのデータ移行さえ済んでしまえば、あとは快適なAWSライフが待っています。データベース運用で苦しんでいる方たちが、このような情報を元に少しでもハッピーになってもらえたらと思っています。
どこかの誰かのお役に立てば嬉しいです。
![[アップデート] Amazon Aurora のモニタリング機能に「CloudWatch Database Insights」が登場しました](https://images.ctfassets.net/ct0aopd36mqt/3nibOl2sZ0LKJueI0FHFi5/14de7bd294f7916a28b789105c60d450/reinvent-2024-newservice-jp.jpg)
